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(54) Data quality management system 

(57) A facility is provided for maintaining automati- 
cally the integrity of data associated with respective data 
applications. The facility achieves this result by provid- 
ing a plurality of data modules (115-1 ,—1 1 5-n) for inter- 
facing respective ones of the applications (110-1,— 
1 1 0-n) with their associated data bases (1 25-1 .—1 25-n) 
such that, in response to receipt of a data request from 
one of the applications, the respective interfacing mod- 
ule unloads the requested data from the associated data 
base. The interfacing module then communicates with 
other ones of the modules to determine if the requested 
data is consistent with related data stored in their asso- 
ciated data bases. If the requested data is found to be 
so consistent, then the data is supplied to the requesting 
application. If not, then the interfacing module corrects 
the inconsistency in accord with predefined data mles, 
and then supplies the corrected data to the requesting 
data application. 
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Description 

FIELD OF THE INVENTION 

The Invenllon relates to managing related data re- 
spectively stored in a plurality of data bases. 

BACKGROUND OF THE INVENTION 

It is often the case that related data may be stored 
in different data bases. For example, a bank may store 
related data such as account information, credit history, 
customer data. etc. in different data bases. It can be ap- 
preciated that over time related data associated with a 
particular account (i.e. a customer) may become incon- 
sistent across the different data bases. As such, when 
data associated with the account is selected by a par- 
ticular banking application from one of the data bases 
and processed, the end result may be incorrect because 
the selected data is not consistent with its associated 
data stored in the other data bases. As another exam- 
ple, in telephone applications different data that is relat- 
ed in some way, e.g. facility, provisioning, and mainte- 
nance data, may be stored in different data bases. If a 
person enters a subscriptkxi for telephone sen^ice, the 
facilities to implement the subscription are selected from 
a provisioning data base. However, the selected facili- 
ties may not actually be available. The reason for this 
may be, for example, that the facilities were marked un- 
available due to maintenance activity and shown as 
such in the maintenance data base, but were inadvert- 
ently left rDarked as available in the provisioning data 
base. As such, a craftsperson would be unsuccessful 
implementing the requested sen/ice as a result of trying 
to use facilities that were not available. It can be appre- 
ciated that the problem of inconsistent data across mul- 
tiple data bases may be both difficult and costly to cor- 
rect. 

SUMMARY OF THE INVENTION 

1 deal with the foregoing problem using what I call 
an Intelligent Data Module (IDM) as an interface be- 
tween an application and its associated data base, in 
which, in accord with an aspect of the invention, the In- 
telligent Data Modules communicate with one another 
to determine if data requested by an associated appli- 
cation is consistent with related data stored in the other 
data bases before the application is allowed access to 
the data. If the data is found to be inconsistent with its 
related data, then the Intelligent Data Module, in accord 
with another aspect of the invention, may invoke either 
a local or a remote data reconcillatkm function to proc- 
ess the related data to make it consistent. 

Other aspects of the invention will be made appar- 
ent in the following detailed descrlptbn and ensuing 
claims. 



BRIEF DESCRIPTION OF THE DRAWING 

In the drawing: 

s FIG. 1 is a block diagram of a system of operational 
applications in which the principles of the invention 
may be practiced; 

FIG. 2 illustrates the logical partitbning of data in a 
10 data base employed in the system of FIG. ^ ; 

RG. 3 is an illustrative example of a Data Element 
Table that is stored in an application database in the 
system of RG. 1; 

IS 

RG. 4 Is an illustrative example of a Master Data 
Element Table that is stored in the data directory of 
FIG. 1; 

20 RG. 5 is an illustrative example of a data record that 
is used to define a respective data object and that 
is stored in the data directory Table of FIG. 1; 

RG. 6 illustrates in a flowchart form the program 
2S which processes a request for application data in 
accord with the principles of the invention; 

RG, 7 is an example of various logical rules which 
may be encoded into the njle base associated with 
30 an Intelligent Data Module of FIG. 1 ; and 

RG. 8 Is an example of various bgical rules which 
may be encoded into the rule base associated with 
the Data Reconciliation Processor of FIG. 1. 

35 

DETAILED DESCRIPTION 

An illustrative embodiment of the invention will be 
discussed in the context of an application involving the 

40 provisioning of telephone sen/ice, which relies on relat- 
ed data stored in a plurality of different data bases, in- 
cluding, for example, facilities, provisioning, and main- 
tenance data bases. It is to be understood that such a 
discussion is not to be taken as a limitatkin of the 

^ claimed invention, since it is merely one applicatbn 
thereof. 

With the foregoing in mind, data bases 125-1 
through 125-N shown in Figure 1 are respectively asso- 
ciated with processors 100-1 through 100-N. Proces- 

50 sors 100-1 through 100-N respectively include Intelli- 
gent Data Modules (IDMs) 115-1 through 115-N, each 
of which supports a respective application. For example, 
IDMs 115-1 through 115-3 respectively support opera- 
tions applications 110-1 through 110-3, identified in FIG. 

55 1 as Facilities. Provisioning, and Maintenance applica- 
tions, respectively. The other IDMs 1 1 5-4 through 1 1 5-N 
support other operations applications not identified 
herein. It is seen that IDMs 115-1 through 11 5-N are driv- 
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en by respective rule bases 120*1 through 120-N, in 
which a rule base Is a set of logically-structured mles 
which directs its associated IDM what actions to take In 
a given situatbn, based upon the consistency of a set 
of related data elements whose values were retrieved 
from respective ones of the data bases 125-1 through 
125-N. 

For example, a telephone company operations ap- 
plication 110-2 may initiate a transaction to request data 
that is needed to perfomn a particular operational task, 
such as the provisioning of new telephone service. In 
accord with an aspect of the invention, the application 
directs the request to its associated IDM. e.g. IDM 
115-2. IDM 115-2, in turn, retrieves the data requested 
by the received transaction, and all of the data bglcalty 
related to the data requested by the received transac- 
tion. Some or all of this logk;ally-related data will nrK>st 
likely have to be retrieved from data bases other than 
data base 125-2. IDM 115-2, upon receipt of the re- 
trieved data, processes the data in accord with particular 
rules stored In its associated rule base 120-2 to deter- 
mine if the retrieved data is logk:ally consistent. If the 
data is found to be consistent, then IDM 115-2 supplies 
the requested data to its associated operations applica- 
tion 1 1 0-2 to complete the desired operational task. Oth- 
erwise, IDM 115-2 proceeds in accord with one of a 
number of different options specified by its associated 
rule base 1 20-2, including the option to suspend the re- 
quest for the data until the data is reconciled, as will be 
discussed in detail below. 

it is seen from Figure 1 that an IDM 11 5i, e.g. IDM 
115-1. Is disposed between its associated operations 
application 1 1 0-1 and the data base 1 25-i, e.g. data base 
125-1, that supports the operations appllcatk)n 110-i. 
This allows each IDM 1151 to control the flow of data 
going to and from its associated application, so that syn- 
chronization of data elements distributed across the da- 
ta bases in the system may be made a conditton of pro- 
ceeding with the use of data in completing any opera- 
tional task of the application. IDM 115-1 through 115-N 
maintain data synchronization by processing each data 
transaction in accordance with rules encoded In their re- 
spective associated rule bases 120-i. ( Such rules are 
generated for each IDM 115i by subject matter experts 
who understand the purpose and functions of the asso- 
ciated application, the logical relationships anfK}ng the 
data elements in all data bases in the system, and the 
relative operational risks and Impacts associated with 
completing certain operational tasks when the data el- 
ements required to complete those tasks may or may 
not be synchronized with logically-related data elements 
In other data bases in the system.) 

For an IDM 1151 to perform its intended function, 
certain attributes and relationships among data ele- 
ments in the system needs to be defined and recorded. 
One such attribute is what I call "ownership", which in- 
dicates for each data element whether single or multiple 
copies of the data element exist throughout the data 
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bases in the system, and, if multiple copies exist, then 
which copy is considered to be the "primary" copy, i.e., 
the copy that Is believed to be more reliably accurate 
than that of any other copy The data base containing 

5 the primary copy of a particular data element, therefore. 
Is considered to be the 'owner* of that data element, (it 
is noted that subject matter experts who design a sys- 
tem of appricatlons also designate whether a data ele- 
ment is a primary copy and thereby kjentify which data 

10 base owns that data element.) A second aspect is what 
I call a "data object", that is defined herein to be the set 
of all the data elements logically related to the data el- 
ement(s) required by an operations applrcatton to com- 
plete a desired operational task, including the data ele- 

15 ment(s) originally requested, as will be described in de- 
tail below. 

Each data element that is stored In a data base 
125-i is associated with an attribute that defines the 
ownership characteristics of that particular copy of the 

20 data element. For example, a data element may be de- 
fined as being (a) "local data" if it is not stored in any 
other data base, (b) "primary shared data' if it is stored 
In multiple data bases, but the copy stored in data base 
1 25i is the primary copy, or (c) 'secondary shared data' 

2S if It is stored in multiple data bases, but the primary copy 
is stored in a data base other than data base 1 25-i. Such 
illustrative identification of all of the data elements in a 
data base 1 25-i as either local, primary shared, or sec- 
ondary shared is illustrated In Figure 2. SpeclTically, the 

30 informatbn that characterizes a data element in the data 
base as local, primary shared, or secondary shared is 
shown as being stored in a respective segment of the 
data base designated a "Data Element Table". (It is to 
be understood of course that FIG. 2 illustrates one way 

3S in which such information may be stored in a data base, 
and that any other similar storage arrangement may be 
used as tong as the stored information may be accessed 
and used in accord with the principles of the invention.) 
An illustrative example of a data element table is 

^ shown in FIG. 3, which is described in detail below. 

One illustrative use of a data element table that Is 
stored In a data base 125-i albws the associated IDM 
1 15i to identity if other copies of data elements request- 
ed by an application exist in other data bases, and. if so, 

45 presences data synch ronizatk>n across the data bases 
in accord with specified rules stored in Its associated 
rule base 120i. Thus, IDM 1151, in a conventtonal man- 
ner, retrieves the ownership attributes associated with 
all requested data elements from the data element table 

so 300 stored in its associated data base 125-1. If all the 
requested data elements are local data, then it is unlike- 
ly that the data elements will be inconsistent with data 
elements in other data bases. In this event, then, IDM 
1151 may be instructed by its associated rule base 120-i 

55 to retrieve the data elements themselves from data base 
1 25-i, and pass them directly to application 1 1 0-i without 
further checking the data elements for consistency. It is 
also possible that the rule base may include a number 

J 
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of rules designed to check for logical consistency be- 
tween data elements, even though the set of local data 
elements were retrieved from the same data base 1 25-i. 
In this event, the processing of these local data ele- 
ments would be similar to that for data elements re- 
trieved from multiple data bases, as discussed below. 
However, in most instances there exists in other data 
bases a number of data elements which either are cop- 
ies of, or are logically related to, the data elements 
stored in data base 125-i. The respective IDM 11 5i, 
therefore, needs to identify the related data elements, 
retrieve them, and process them in accord with the rules 
stored in its associated rule base 120-i to determine if 
the data elements are consistent with one another 

In the event that an application UO-i has to modify 
a particular shared data element, then 'ownership' is 
used to ensure that all copies of that data element are 
also nrKxJified. If an IDM 11 5i receives such a request 
from its associated application, then the IDM 11 5i first 
identifies the number and location of all such copies of 
that data element. Since the data element table that is 
in a particular data base identifies the ownership at- 
tributes only for the data elements stored in its "own" 
data base, then the IDM 11 5i must use another mecha- 
nism to be able to locate conveniently the other copies 
of the data element. One such mechanism may be re- 
alized by storing centrally the information in all of the 
data element tables 300 in the system as well as pro- 
viding a cross-reference identifying logically-related 
shared data elements. This is done using what I call a 
■master data element table" that is stored in data direc- 
tory 150 (FIG. 1). 

The master data element table 400 shown in FIG. 
4, more particularly, provides a comprehensive cross- 
reference for all data elements stored in all of the system 
data bases 1 25i. For a shared data element, master da- 
ta element table 400 identifies the number, locations, 
and ownership attributes of all copies of the shared data 
element across all data bases I25i in the system. The 
Master data element table thus allows an IDM 11 5i to 
retrieve in one transaction with the Data directory all the 
data element informatbn needed to complete the wod- 
ification of a shared data element. An example of the 
information contained in the Master data element table 
is shown in Figure 4. 

For example, whenever an IDM 11 5i needs to mod- 
ify a particular shared data element, IDM 11 5i must first 
determine from the data element table 300 stored in its 
associated data base 125i it the data element to be up- 
dated is a shared data element. If so, then IDM 1 1 5i must 
form and send a message to the Data directory 1 50 re- 
questing the names and locations of all copies of the 
shared data element resident in other data bases and 
identified in the master data element table 400 stored in 
directory 150. Data directory 150, in turn, accesses the 
requested information and retums it to IDM 115i. If, on 
the other hand, the shared data element is stored in da- 
tabase 1 25i associated with IDM 1 1 5i and is the primary 



shared copy, then I DM 1 1 5i in accord with rules specified 
in its associated rule base 1 20i may update immediately 
that copy of the shared element. IDM 1 1 5i then sends a 
copy of the updated data element to the other IDMs 115 
s to update the secondary shared data element copies 
stored in their respective data bases 125. If, however, 
the shared data element that is stored in data base 1 25i 
is a secondary shared copy, then IDM 115i, in accord 
with the rule specified in its associated rule base 1 20i, 
'0 must obtain permission to update the data element from 
the IDM 115 having ownership of the primary shared 
copy Such pennission may be granted immediately up- 
on request, or may trigger another series of actions by 
the latter IDM 1 1 5 before permission is either granted or 
IS rejected. 

The descriptbn of the data element tables and Mas- 
ter data element table in the paragraphs and example 
above is not intended to define or constrain the method 
in which this information is included in the system archi- 
20 tecture, but merely to construct a convenient reference 
model for describing the workings of other aspects of 
the invention. 

(It is noted that the foregoing discussion of tables 
300 and 400 is not to be construed as a limitatkxi since 
25 there may be a number of architectural alternatives 
which could be used to implement either data table. For 
exarriple. in some applications, it may be more conven- 
ient to provide only master data element table 400 and 
not data element tables 300. In this instance, an IDM 
30 11 51 wou W have to query master data element table 400 
each time it needs to identify a data element, Alterrra- 
tively a copy of a master data element table 400 may 
be stored in each of the data bases 125 or IDMs 115.) 
A data object, as defined above, is central to the 
35 preservation of data synchronization across all data 
bases in the system. A data object for a particular oper- 
ational task is the complete set of data elements within 
which data consistency needs to be validated to ensure 
data quality is being preserved while the operational 
40 task is being completed. Data consistency within a data 
object is validated through application of the rules de- 
signed for this purpose. To ensure the presentation of 
data quality across a system of applications, a data ob- 
ject needs to be defined for each operational task which 
45 either uses or affects critical data elements. While data 
objects will be different for different operational tasks, 
the definirton of a data object for a task needs to be 
standardized. For this reason, the definitions of data ob- 
ject for respective system operational tasks may be 
50 stored in data directory 1 50, as will be discussed below. 
Storing the definition of a data object in data direc- 
tory 150 provides a means for an IDM 115i to identify 
and locate a desired data element whrch is a part of the 
data object defined for a particular operational task. An 
55 IDM 11 5i may do this in the following manner. 

Specifically, the unique identification associated 
with all data elements forming a data object are stored 
as a record in data directory 150. (If desired, the data 
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object definitbn might also include for each data ele- 
ment its ownership characteristics (e.g. local vs. primary 
shared vs. secondary shared)). In a data directory 
record, a referenced data element may be described by, 
for example, the identity (e.g. the conventional address- 
able name) of the data base storing the data element, 
and the identity (e.g. the conventional addressable 
name) of the data element in that data base. A logical 
illustration of such a data record stored in data directory 
150 is shown in FIG. 5. Record 500 is used to define a 
data object for a task entitled Circuit Provisioning. 

A flowchart of an illustrative software program 
which implements the principles of the invention in an 
IDM 115i, e.g., 115-1, is shown in FIG. 6. Specifically, 
responsive to receipt of a request for particular opera- 
tional data from its associated application 110-1, the 
program is entered at block 600 and proceeds to 601 to 
receive the data request. The program (block 602) then 
consults Its associated data element table 300 (stored 
in its associated data base 1 25i as mentioned above) to 
determine if the requested data elements are local data 
or shared data (either primaiy or secondary). If the pro- 
gram (block 603) detennines that the requested data el- 
ements are all local, then program (block 61 5) retrieves 
the requested data elements from its associated data 
base 1251. and supplies (block 614) the retrieved result 
in a conventional manner to the requesting application. 

If the program determines that some of the data el- 
ements are shared data elements, then the program 
(block 604) forms a message requesting the data record 
defining the data object for the operational task identi- 
fied by the application and sends the message to data 
directory 1 50. Upon receipt of the message, data direc- 
tory 150, using an kientifier that is contained in the mes- 
sage and that identifies the operational task that wilt use 
the data, translates the kientifier into a memory location. 
Data directojy 150 then accesses that memory location 
in associated memory to retrieve a copy of the data 
record defining the data object needed to verify the con- 
sistency of the data that will be processed by the spec- 
ified task. Data directory 1 50 then sends the copy of the 
data record to the IDM 115-1 which originated the re- 
quest. 

Upon receipt of the record from data directory 150, 
the program (block 605) assembles the required data 
object by collecting all of the data elements identified in 
the record received from data directory 1 50. In doing so. 
the program forms and sends a message requesting da- 
ta to each of the other IDMs 115i. e.g. IDM 115-2 and 
115-3, whose associated data base 125i contains data 
elements klentifted in the received record. Responsive 
to receipt of such a message, a receiving IDM 115i, e, 
g. IDM 115-2. retrieves in a conventional manner a copy 
of the requested data from its associated application da- 
ta base, e.g. 1 25-2, and retums the copy to the IDM 1151 
program that requested the data. The IDM 115i pro- 
gram, responsive to receipt of the requested data ele- 
ments from its own data base and from other IDMs 1 1 5i. 



assembles the received data into the desired data object 

and stores the data object in associated memory. 

Following through on the example, the program 
(block 606) then processes the contents of the data ob- 
s ject in accord with the rules stored in its associated rule 
base 1201 to detemiine if the data elements fomning 
such contents are logically consistent with each other. 
Such processing typically involves invoking a series of 
steps that compare multiple data elements in the data 
10 object with (a) each other, and (b) reference values en- 
coded in the rules, to determine if the data elements sat- 
isfy the conditions specified in the rules. If the program 
finds that the data elements satisfy the conditions spec- 
ified in a partrcular rule, then the program concludes that 
IS the data elements 'pass', i.e.. are consistent with re- 
spect to that mie. Otherwise, the program concludes 
that the data elements fair that rule, i.e.. are inconsist- 
ent with respect to that rule. 

In the same manner, the program (block 606) proc- 
20 esses the data object for each mle in rule base 120-1 
defined for that data object. If the program (block 607) 
detemnines that the data object passes each such rule, 
then the program (block 61 4) supplies the requested da- 
ta to the applicatbn. If, on the other hand, the program 
25 (607) determines that the data object failed one or more 
rules, then the program (block 608) may apply so-called 
correction rules stored in rule base 120-1 as a way of 
attempting to reconcile the inconsistency using other 
data elements in the data object (and possibly by using 
30 other data elements outside the data object retrieved for 
just this purpose). If the program (block 609) finds that 
such correction rules are successful meaning that one 
or more elements of the data object were changed to 
get the data object to pass all of the previously failed 
35 rules - then the program (block 61 6) sends the changes 
(update) to all of the IDMs whose associated data bases 
contain the data elements to be corrected. Such sending 
directs those IDMs to make the same data element cor- 
rections as were made in the data object. Where such 
40 correction rules exist and can be successfully applied, 
the result will be that the data object will be ultimately 
found to be consistent. Foltowing the sending of the up- 
dates to the affected IDM's, the program (block 614) 
supplies the requested data to the application. 
45 When the appfication of correctton rules fail to make 
a data object consistent, the program (block 610) sends 
a request to data reconciliation process (DRP) 175 to 
reconcile the data forming the data object and then the 
program (block 611) evaluates the result to see if the 
50 data object is consistent. If so, the program (614) sup- 
plies the requested data to its associated applicatbn 
110-1 to complete the desired operational task. If not, 
and the program concludes that the inconsistency can 
not be corrected by the appfication of respective correc- 
ts tion rules, then the program consults its rule base to de- 
termine what action to take to deal with the inconsistent 
data. For example, the rule base may instruct the pro- 
gram to (a) instruct the requesting application to sus- 
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pend the operational task if it is in progress, and wait 
until the data Inconsistency has been reconciled by the 
Data Reconciliation Processor (DRP) 175 (FIG. 1), (b) 
supply the requested but inconsistent data to the appli- 
cation together with a warning noting the inconsistency, 
or (c) refer the inconsistent data object to DRP 175 with 
a request to Initiate a search for alternative data, as is 
illustrated in FIG. 6 (block 612). 

Specifically, responsive to receipt of a data object 
containing inconsistent data f rom an IDM 1 1 5i, DRP 1 75 
processes the data object in accord with a set of correc- 
tion njles contained in its associated rule base 180. Us- 
ing such correction rules, DRP 1 75 attempts to reconcile 
inconsistent data elements using infomiation already in 
the data object, and possibly also other data elements 
outside the data object (called reference data elements) 
that may be retrieved from other data bases 1 25i. Such 
other data may serve to substantiate or invalidate the 
value of a partrcular data element in the data object. The 
rules that DRP 1 75 uses are based upon knowledge ob- 
tained from by experts having particular experience with 
respect to evaluating and resolving inconsistency in da- 
ta elements. 

For example, a cable pair status from the provision- 
ing portbn of the data object (i.e. that portion of the data 
object whose data elements are taken from the provi- 
sioning data base 125-2, FIG, 1) may be "available", 
meaning that the cable pair is sennceable and available 
for assignment, i.e. not currently in use. However, if at 
the same time the cable pair status in the maintenance 
portion of the data object (obtained from maintenance 
data base 125-3. FIG. 1) is "unavailable", and this in- 
consistency can not be resolved by the IDM 115i rule 
base, then the inconsistency may be referred by that 
IDM to DRP 175 for reconciliation. DRP 175, using the 
rules encoded in rule base 180, tries to determine which 
data element is correct, i.e., the cable status shown in 
the provisioning portbn of the data object, or the cable 
pair status shown in the maintenance portbn. 

As afurther example, the rules in rule base 180 may 
direct DRP 175 to make that determination by checking 
the most recent date that a trouble was reported on the 
cable pair. DRP 175 would then access the mainte- 
nance data base 125-3 via its associated IDM 115 to 
obtain the data element recording that date. If the date 
is within a specified perkxf of time, for example, in the 
last seven days before the current date, then rule base 
180 might direct DRP 175 to (a) declare that the cable 
pair is indeed out of sen/lce, (b) correct to "unavailable" 
the value of the cable pair status in the provisioning por- 
tion of the data object, and (c) send to IDM 115-2 a re- 
quest to update to "unavailable" the cable pair status in 
the provisioning data base 1 25-2. DRP 1 75 then contin- 
ues in a similar manner to reconcile any other inconsist- 
ent data in the data object. 

If the aforementioned date of the wosi recent re- 
ported trouble is not within the specified period of time, 
then rule base 180 may. for example, direct DRP 175 to 
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declare that the correct cable pair status is 'available', 
and update to 'available' the cable pair status in the 
maintenance portion of the data object, as well as in the 
maintenance data base 125-3. When DRP 175 com- 
s pletes the reconciliation function in this manner, all log- 
k:ally-related data elements in the data object, and in 
the respective data bases from which the data object's 
data elements are drawn, will be consistent according 
to the mles in rule base 180. 
10 If DRP 1 75 can not detemnine conclusively with the 
available Information the correct value for the cable pair 
status, rule base 180 may direct DRP 175 to produce a 
message or report requesting a manual data base 
check, and/or a field verification of the cable pairs in- 
15 volved. At this point, DRP 1 75 may send a message to 
IDM 1151 indicating it was not able to reconcile the in- 
consistency, whereupon IDM 115i, in accordance with 
operational rules in its associated data base 120-i, may 
discard the data object and initiate a search for altenfia- 
20 tive data. 

Assume that the data object can be made consist- 
ent without such manual verificatron. and that IDM 11 5i 
had suspended the operational task and was waiting for 
a response from DRP 175 in accord with case (a) men- 
25 tloned above. Then DRP 175 will return the now con- 
sistent data object to IDM 11 5i with a message indicating 
that the inconsistency has been reconciled. IDM 1151. in 
accord with its own operatbnal mles stored in its asso- 
ciated rtJle base 120i, may (a) then revalidate the data 
30 object to confirm the consistency in accord with the val- 
idation rules stored in that rule base, (b) goon to another 
interim task, or (c) immediately supply the requested da- 
ta to the requesting application. 

With the foregoing in mind, an illustrative example 
$s of applying the principles of the invention will now be 
discussed, using the operational task of provisioning a 
leased lines circuit. Assume that the system Illustrated 
In Figure 1 is associated with a telecommunications sys- 
tem and comprises three applications supported by fa- 
40 cilities processor 100-1, provisk)ning processor 100-2 
and maintenance processor 100-3. 

Also assume that the three appKicattons have as 
part of their associated data bases data elements which 
describe partk:ular transmission paths available In the 
45 telecommunications system, namely, path Id, facility 
type, end points, and current operational status. The da- 
ta elements also describe (a) the circuits already in use 
in the network (circurt id, circuit type, component path 
segments, circuit end points, and current operational 
so status), and (b) maintenance troubles recently incurred 
(trouble record id. affected path id. date last trouble re- 
ported, and date last trouble cleared). Some of these 
data elements are local to only one applicatk>n, and the 
rest are shared among two or all three of the applica- 
55 tions. The identities of the particular data elements and 
their type (local, primary shared, or secondary shared) 
are recorded in the data element tables In each of the 
data bases respectively associated with the three appli- 
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cations, such as Table 300 illustrated In Figure 3 for the 
provisioning data base. Master data element table 400, 
FIG. 4. contains all of the data element table information 
and cross-references needed to identify shared data el- 
ements stored in different data bases. The data object 
defined for circuit provistoning, with all its constituent da- 
ta elements, is stored in data directory 150, as shown 
in Figure 5. 

Assume at this point that a telephone customer 
places an order for a leased lines circuit from Denver to 
Chicago with an agent of the telecommunications sys- 
tem having control over provisioning application 110-2. 
The agent, in turn, communicates in a conventional 
manner with application 110-2 via provisioning proces- 
sor 100-2 to ascertain the optimum routing for the re- 
quested circuit. The provisioning application In a con- 
ventional manner determines such optimum routing, 
and outputs (e.g., displays on a computer screen) infor- 
mation describing the requested routing. Such routing 
may comprise three segments, namely, segment At rom 
Denver to Kansas City, segment B from Kansas City to 
St. Louis, and segment C from St. Louis to Chicago. The 
provisioning application may also output other aspects 
associated with the routing, e.g., sen/lce features, pric- 
ing, etc. If the output is acceptable to the customer, then 
the agent executes the order via the provisioning appli- 
cation, and waits for confirmation therefrom that appro- 
priate facilities and segments are available and have 
been resen/ed for this customer order. 

While the agent waits for such confirmation, the pro- 
visioning application 110-2 automatically initiates the 
process of finding specific path segments available to 
form the optimum route. To do this, application 110-2 
supplies to its associated IDM 115-2 infomnation de- 
scribing the characteristics of the desired circuit and the 
need for optimum routing. It also requests from IDM 
115-2 the circuitjd and path_id identifying each circuit 
segment that will form the route, and a confirmation of 
operational status (ckt.status) of each such circuit. 

IDM 115-2, in tum, searches for three path seg- 
ments that may be used to form the optimum route and 
have a path_status of "OK" - meaning that the path is 
both sen^iceable and available tor assignment. Using 
the information provided by provisioning application 
1 1 0-2 and the data elements stored in provisioning data 
base 125-2, IDM 115-2 first identifies the path.id's of 
those paths which quality as good candidates for seg- 
ments because they satisfy the specified circuit require- 
ments and have a path_status of "OKV [DM 115-2 may 
also be directed to identify other suitable candidates 
with path status "NOK' (not serviceable) for evaluation, 
as discussed below. Once the candidate paths are iden- 
tified, IDM 115-2 then ensures that the data elements 
describing each identified path candidate are consistent 
with any logically -related data elements in both the fa- 
cilities and n^intenance data bases 125-1 and 125-3, 
respectively. IDM 1 1 5-2 does this by (a) determining the 
identity and location of such related data elements, (b) 
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retrieving those data elements, and (c) assembling them 
into the data object prevtously defined for the circuit pro- 
visioning task. I DM 1 1 5-2 then examines the data object 
according to the rules in rule base 120-2 to ensure that 

5 the data object conforms with (i.e., passes) all of the rel- 
evant rules stored therein, or can be corrected to pass 
all such rules. 

IDM 115-2, more particularly First consults data el- 
ement table 300 stored in its associated data base 1 25-2 

10 to determine which of the required data elements are 
identified as local and which are identified as shared. If 
some of the required data is found to be shared data, 
and therefore logically-related data elements are stored 
in other data bases, then IDM 115-2 sends a message 

IS to data directory 150 requesting a copy of the data 
record for the circuit provisioning data object, as dis- 
cussed above. Data directory 150, in tum, returns the 
requested data record, in which the data record identi- 
fies (a) all of the data elements defined to be a part of 

20 the circuit provisioning data object, and (b) the data base 
respectively containing each such data element. The 
logical structure of the information contained in data di- 
rectory 150 for the requested circuit provisioning data 
object is shown in FIG. 5. Using such information, IDM 

25 1 1 5-2 then assembles and validates in sequence the re- 
spective data objects for the path candidates that could 
form the desired circuit segment. In particular, IDM 
115-2 first collects all relevant data for path segment A 
from Denver to Kansas City In doing so, IDM 115-2 ob- 

30 tains from its associated data base 1 25-2 all of the pro- 
visioning data elements identified in the data object. IDM 
115-2 also obtains from IDM 115-1 and IDM 115-3 the 
related data elements that are respectively stored in fa- 
cilities and maintenance data bases 125-1 and 125-3. 

35 IDM 115-2 assembles the latter data elements as they 
are received from those data bases into a circuit provi- 
sioning data object. IDM 115-2 then temporarily stores 
the assembled data object in internal memory so that 
the elements forming the stored data object may be an- 

40 alyzed for consistency in accord with the logical rules 
stored in rule base 1 20-2. An illustrative example of such 
logical njles is shown in FIG. 7, Accordingly, when IDM 
115-2 has completed assembling the data object it then 
applies the logical rules to the data forming the object 

4S to determine if path A satisfies the specification set forth 
in the agent's order for the first segment of the desired 
circuit. 

Specifically the rules shown in FIG. 7 specify differ- 
ent actions that may be taken based on the value of the 

so three path_status data elements obtained from the fa- 
cilities, provisioning, and maintenance data bases, re- 
spectively. For the instant example, assume that the val- 
ues for a path^status could be (a) 'OK", which means 
that the path is serviceable and available for use in a 

55 circuit, (b) "NOK", which means that the path is unavail- 
able due to a current trouble condition, or (c) "ON", 
which means that the path is working and has been as- 
signed to another circuit. Also assume that all of the 
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paths having a status of 'ON' were 'screened out' in an 

earlier candidate selection process, such that they need 
not be considered in the following discussion. 

Assume at this point that the path_status received 
for Path A from each of the data bases 125-1 through 
125-3 is 'OK' - meaning that Path A meets technical 
requirements specified for the desired segment, is sen^- 
iceable and available for assignment, and that all data 
elements defining Path A are consistent across data 
bases 1 25-1 through 1 25-3. Once the consistency of the 
data object for Path A has been validated In accord with 
the rules in mie base 120-2, then IDM 115-2 again in 
accord with those rules reserves Path A as the first seg- 
ment of the desired circuit. IDM 115-2 does this by cre- 
ating a record for circuit segment 1 with the value of the 
pathjd for Path A, and by updating the path_status for 
Path A in data bases 125-1 through 125-3 from "OK' to 
'ON', since it is being assigned to this circuit. 

Once IDM 1 1 5-2 has completed ail tasks associated 
with resen/ing path A as the first segment of the desired 
customer circuit, then IDM 115-2 may then begin the 
process of determining if path B is a good candidate for 
the second segment of the desired circuit. Assume, 
then, that the path_status received from data bases 
125-1 through 125-3 for path B are "OK', "NOK", and 
'OK', respectively. For this case, then, the rules (as 
shown in FIG. 7) instruct IDM 115-2 to check the value 
of the tbl_date_clr data element from data base 125-3. 
Assume that the tbLdate_clr element indicates that the 
last trouble on path B had been cleared three days prior 
to the date of current servtee request. For the purposes 
of this example, it is known by the skilled artisan that 
when the path^status for a circuit in the provisioning and 
facilities data bases disagree with each other and the 
maintenance data base indicates that the trouble in that 
path had been cleared within the last seven days, then 
it would be safe to assume that the path is OK, and that 
the data base which indicates 'NOK' is not correct. In 
that case, then, the rule directs IDM 115-2 to instruct 
facilities IDM 115-1 to update data base 125-1 accord- 
ingly, i.e., correct the path_status data element for path 
B to 'OK', and then to resen/e path B as the second 
segment of the desired circuit. Once those activities are 
completed, IDM 115-2 may then process path C as a 
candidate for the final segment 

Similarly, IDM 115-2 processes the data for path C 
to determine if it is acceptable for use. Assume at this 
point that the path_status received from (a) provisioning 
data base 125-2 is "NOK', (b) facilities data base 125-1 
is "OK", and (c) maintenance data base 125-3 is "OK'. 
Also assume that the tbLdate^clr element received 
from maintenance data base 125-3 indicates that the 
last recorded trouble was cleared more than seven days 
ago. Based on this information for this particular 
path_status. a skilled artisan would conclude that further 
investigation must be done to determine the cause of 
the inconsistency. The rules shown in FIG. 7, therefore, 
direct IDM 115-2 to reject Path G and to then \oca\e an 
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alternate path that may be used as the last segment in 
the circuit path C. Such rules also direct that the incon- 
sistency in the path C data should be referred to DRP 
175 for detailed processing. Accordingly, assume at this 
5 point that a further search indicates that altemate path 
CI is available between St. Louis and Chicago, and that 
path CI satisfies the rules stored in rule base 1 20-2 such 
that IDM 115-2 wouW be directed to reserve path CI as 
the last segment in the desired circuit. 
10 Once paths A. B, and CI have been identified and 
resented for the desired circuit, IDM 115-2 (a) associ- 
ates the circuit with a unique circuit_id for this circuit; (b) 
records the pathjd for the three selected segments as 
ckt_seg_1 , ckt_seg_2. and ckt_seg_3, respectively; (c) 
15 records that the ckl_status is 'OK', and (d) returns in- 
fomnation to this effect to the provisioning application. 
The provisioning application, in tum, displays the infor- 
nrtatk)n on the display of a computer operated by the 
aforementioned agent. The agent may then inform the 
20 customer that the desired circuit from Denver to Chicago 
has been confirmed. 

FIG. 6 illustrates one example of logical rules that 
DRP 175 could emptoy to reconcile the aforementioned 
data for path C. To repeat the above example for path 
25 c, data bases 125-2, 125-1 and 125-3 indicated a 
path_status of 'NOK', "OK", and 'OK', respectively, with 
a tbLdate^clr of okJer than seven days. For this case, 
the DRP 175 mies specify checking the consistency of 
the path.type between the maintenance and facilities 
30 data bases as the next processing step. This is done 
since it is possible that a trouble report may have been 
recorded in the maintenance data base against the 
wrong pathjd, and the most reliable source of 
path_type is contained in the facilities data base, where 
35 the primary shared copy for the path is stored. If the 
path^types match, then the data for the end points of 
path C are similarly checked. If either the path_type or 
end points are found to be inconsistent, then the DRP 
175 rules specify that the data be checked manually, 
40 which might result in a field verification. If, on the other 
hand, DRP 1 75 finds that the data for the path Jype and 
end points match, then the DRP 175 rules specify that 
the path_status recorded in the provisioning data base 
is incorrect, and direct an update of the path_status data 
45 element in that data base. At this point, then, since path 
C is no longer needed for the illustrative circuit, it is made 
available for use in another circuit. 

The foregoing is merely illustrative of the principles 
of the invention. Those skilled in the art will be able to 
so devise numerous arrangements, which, although not 
explicitly shown or described herein, nevertheless em- 
body those principles that are within the spirit and scope 
of the inventkx). 

55 

Claims 

1 . Apparatus comprising 



EP0807 892A2 



8 



15 



EP0 807 892A2 



16 



a pturatity of data bases for storing data asso- 
ciated with respective applications, 

a plurality of data modules for interfacing re- 
spective on es of said applications with their as- s 
sociated data bases, and 

means, contained in each of the data modules 
and responsive to receipt of a request from an 
associated one of said applications requesting 10 
particular data stored in the associated one of 
said data bases, for unloading the requested 
data from the associated one of said data bases 
and for communicating with individual other 
ones of said data modules to determine if the 
requested data is consistent with related data 
stored in their associated ones of said data bas- 



2. The apparatus of claim 1 wherein said means for 20 
communicating includes means, operative in the 
event that said requested data is determined to be 
consistent with said related data stored in said as- 
sociated ones of said data bases, for supplying said 
requested data to the associated one of said appli- 2S 
cations. 

3. The apparatus of claim 1 wherein said means for 
communicating includes means, operative in the 
event that said requested data is determined to be 30 
inconsistent with said related data stored, for rec- 
onciling the inconsistency between said requested 
data and said related data. 

4. The apparatus of claim 1 wherein each of said data 35 

modules is associated with respective rule bases, 
each of said rule bases comprising a plurality of 
specifications specifying how the associated mod- 
ule is to process related data that is inconsistent 
with requested data, and wherein said means for 40 
communicating includes means, operative in the 
event that said requested data is determined to be 
inconsistent with said related data, for processing 
said requested data and said related data in accord- 
ance with the specifications stored in the associated <s 
one of said rule bases. 

5. The apparatus set forth in claim 1 further comprising 

means for determining which of said associ- 
ated ones of said data bases contain said related so 
data, if any, and for sending a message requesting 
said related data to each of said associated ones of 
said data bases that contains said related data. 



6. Apparatus comprising 

a plurality of data bases, ones of said data bas- 
es being associated with respective applica- 
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tions. said data bases containing data associ- 
ated with said applications 
a plurality of data modules associated with re- 
spective ones of said data bases, 
means, contained in at least one of said data 
modules and responsive to receipt of a request 
from one of said applications requesting partic- 
ular data contained in that one of said data bas- 
es associated with said at least one of said data 
modules, for unloading said requested data 
from said one of said data bases, 
means, contained in said at least one of said 
data modules, for identifying which of other 
ones of said data bases contain data related to 
the requested data and for sending a request 
for a copy of said related data to each of said 
other ones of said data bases via their associ- 
ated one of said data modules, and 
means, contained in said at least one of said 
data modules and responsive to receipt of said 
related data, for supplying said requested data 
and said related data to said one of said appli- 
cations if said requested data and said related 
data are consistent with each other. 

7. The apparatus of claim 6 wherein said means for 
supplying includes means, operative in the event 
that said requested data is determined to be incon- 
sistent with said related data stored, for reconciling 
the inconsistency between said requested data and 
said related data. 

8. The apparatus of claim 6 wherein said data mod- 
ules are associated with respective mie bases each 
comprising a plurality of specifications specifying 
how the associated module is to process related da- 
ta that is inconsistent with requested data, and 
wherein said means for supplying includes means, 
operative in the event that said requested data is 
determined to be inconsistent with said related da- 
ta, for processing said requested data and said re- 
lated data in accordance with the specifications 
stored in the associated one of said rule bases. 

9. The apparatus of claim 4 or 8 wherein said specifi- 
cations include a specificatbn to postpone supply- 
ing said requested data to said associated one of 
said applications until the inconsistency between 
said requested data and said related data is recon- 
ciled. 

10. The apparatus set forth in claim 5 or 6 further com- 
prising a Data directory for storing a plurality of 
records each identifying which of said data bases 
contain data related to requested data, and identi- 
fying which data elements in said data bases are 
related to said requested data. 



9 



EP0807892A2 



FIG. 1 
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FIG, 3 
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FIG. 4 
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FIG. 5 
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FIG, 6 
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FIG, 7 

Do for Each Circuit Segment i=1 to N: 
Do for Each Candidate Poth j=1 to N: 

If P_path_status=OK and F_path_status=OK and M_path_status=OK 
then reserve F_path_id as ckLsegmenLi; 

If P_poth_stotus=OK ond F_polh_stotus=OK and M_paUi_status=NOK 
then refer case to Data iieconciliation Processor 
and select alternate path; 

If P_path_stotus=OK and Lpath_status=NOK and M_palh_slatus=OK 
then if M_tbLdate_clr is less than seven days before current dote 
then update F_pcth_stotus to OK 

and reserve F_potLid as ckLsegmenLi; 
else refer case to Data Reconciliation Processor 
and select oltemate path; 

If P_poth_status=OK and F_poth_status=NOK and M_path_status=NOK 
then update P_path_status to NOK 
and select alternate path; 

If P_path_status=NOK and F_potLstfltus=OK and M_path_stfltus=OK 
then if M_tbLdate_clr is less than seven days before current dote 
then update P_path_status to OK 

and reserve F_patLid as ckLsegmenLi; 
else refer case to Data Reconciliation Processor 
and select oltemote poth; 

If P_path_status=NOK and F_path_stotus=OK and M_path_stotus=NOK 
then update F_path_status to NOK 
and select altemote path; 

If P_path_status=NOK and F_path_stfltus=NOK and M_path_status=OK 
then refer cose to Data Reconciliation Processor 
and select oltemate path; 

If P_path_stotus=NOK and F_paULstatus=NOK and M_poth_status=NOK 
then select olt«mate path; 
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FIG. 8 



Do for Eoch Cose Referred from on Intelligent Ooto Module: 

If P_poth_status=OK and F_()oth_status=OK ond M_potlLstatus=NOK 
then if M_tbLdole_rpt is less than seven days before current dote 
then if M_tbLdote_clr is pending 
then updote F.path.status to NOK 

ond updote P_path_$tQtus to NOK 
else updote M_path_status to OK 
else request manual verification; 

If P_path_status=OK ond F_path_status=NOK and M_paUi.status=OK 
then if M_tbLdate_clr is less than seven days before current dote 
then update F_path_status to OK 

else if K_path_type = F_poth_type . . r . oi 

then if [M_poth_end_1,M_path_end.2]=[F_patLend_l, F_path_end_2J 

then update F.poth_stotus to OK 
else request Maintenance Data Base check 
else request Mointenonce Data Base check; 

If P poth_status=NOK ond F_path>status=OK and M_poth.status=OK 
then If ~M_tbLdote.clr is less than seven days before current dote 
then update P.path_status to OK 
else if M_path_type = F_path_type 
then if [M_path_end_1, M.path_endJ]=[F_path.end_l. F_poth_end_2J 
then update P„path_stotus to OK 
else request Maintenance Data Base check 
else request Mointenonce Doto Bose check; 

If P.path_status=NOK and F_pQtLstatus=NOK and M_path_status=OK 
then if M_tbLdate.clr is less than seven days before current dote 
then update P_path«status to OK 

and update F.path_status to OK 
else request monuol verificotlon; 
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